Özel Yazılım Fiyatlandırma Modelleri: Sabit Fiyat mı, Süre Bazlı mı, Sonuç Bazlı mı?

“Özel yazılım ne kadara mal olur?” yanlış sorudur. Doğru soru şudur:

“Bu projeyi hangi fiyatlandırma modeliyle yönetmeliyim?” Çünkü aynı proje, kullanılan modele göre 2-3 kat farklı maliyetlere ulaşabilir. 800 bin TL’ye sabit fiyatla başlayan bir proje, 18 ay sonunda kapsam değişiklikleri, ek geliştirmeler, hata düzeltmeleri ve yeniden yazım maliyetleriyle 2,4 milyon TL’ye çıkabilir. Aynı proje süre ve emek bazlı modelle yönetildiğinde 1,1 milyon TL’de tamamlanabilir. Çünkü süreç daha şeffaftır, değişiklikler kontrollü ilerler.

Sonuç bazlı modelde ise yazılım firmasının motivasyonu sizin hedeflerinizle hizalanır. Ancak model yanlış kurulursa firma projeden erken çekilebilir ve süreç yarım kalabilir.

Yani fiyatlandırma modeli yalnızca sözleşme detayı değildir. Projenin başarısını doğrudan etkileyen stratejik bir karardır.

Bu yazıda dört temel modeli inceliyoruz:

- Sabit Fiyat

- Süre ve Emek Bazlı

- Sonuç Bazlı

- Hibrit / Fazlı Model

Hangi projede işe yaradıklarını, hangi durumlarda sorun çıkardıklarını, gerçek maliyet etkilerini ve sözleşmede dikkat edilmesi gereken noktaları karşılaştırıyoruz.

4 Temel Fiyatlandırma Modeli

Sabit Fiyat

- Risk: Görünürde yazılım firmasında, gerçekte çoğunlukla müşteride

- Esneklik: Düşük

- Uygun proje tipi: Kapsamı net küçük projeler

- Ortalama nihai maliyet: İlk teklife göre genelde %150-200

Süre ve Emek Bazlı

- Risk: Müşteride

- Esneklik: Yüksek

- Uygun proje tipi: Keşif sonrası geliştirilen projeler

- Ortalama nihai maliyet: Genelde %95-110

Sonuç Bazlı

- Risk: Taraflar arasında paylaşılır

- Esneklik: Orta

- Uygun proje tipi: Ölçülebilir hedefi olan projeler

- Ortalama nihai maliyet: Başarı kriterine göre %90-130

Hibrit / Fazlı Model

- Risk: Aşamalı paylaşılır

- Esneklik: Yüksek

- Uygun proje tipi: Çoğu kurumsal proje

- Ortalama nihai maliyet: Genelde %100-120

Model 1: Sabit Fiyat

Nasıl Çalışır?

Yazılım firması tüm kapsamı kabul eder ve tek fiyat verir. Proje belirlenen teslim aşamalarına göre ilerler.

Ne Zaman İşe Yarar?

- Keşif ve tasarım süreci tamamlandıysa

- Veri modeli, ekranlar ve entegrasyonlar netse

- Küçük ölçekli projelerde

- Benzer projeler daha önce yapıldıysa

- Süreç boyunca kapsam değişmeyecekse

Ne Zaman Sorun Çıkarır?

- Proje kapsamı net değilse

- 6 aydan uzun projelerde

- Ürün yönü değişmeye açıksa

- Regülasyon veya kullanıcı geri bildirimi süreci etkileyebilecekse

- Yeni teknoloji veya Ar-Ge içeriyorsa

Gerçek Maliyet

2024-2026 verilerine göre sabit fiyatlı projelerin büyük bölümü başlangıç bütçesini %30-150 arasında aşar.

En büyük neden:

“Kapsam dışı” olarak değerlendirilen işlerin sonradan ek ücretlendirilmesi.

Dikkat Edilmesi Gerekenler

- Kapsam dokümanı sözleşmeye eklenmeli

- Ek geliştirme ücretleri önceden tanımlanmalı

- Kabul kriterleri ölçülebilir olmalı

- Gecikme cezaları sözleşmede yazmalı

Model 2: Süre ve Emek Bazlı

Nasıl Çalışır?

Ödeme, harcanan süreye ve ekip kapasitesine göre yapılır.

Örneğin:

- 1 proje yöneticisi

- 3 geliştirici

- 1 test uzmanı

Aylık veya iki haftalık periyotlarla faturalandırılır.

Ne Zaman İşe Yarar?

- Modern kurumsal projelerin çoğunda

- Kapsamın zamanla değişeceği projelerde

- Yeni ürün geliştirme süreçlerinde

- Yapay zeka ve Ar-Ge projelerinde

- İç ekip proje yönetimini takip edebiliyorsa

Ne Zaman Sorun Çıkarır?

- İç ekip süreci yönetemiyorsa

- Üst bütçe sınırı belirlenmemişse

- Sprint toplantıları takip edilmiyorsa

- Saat raporlaması şeffaf değilse

Gerçek Maliyet

Bu modelde projeler çoğunlukla tahmin edilen bütçeye yakın tamamlanır.

Çünkü sorunlar erken görünür hale gelir ve değişiklikler süreç içinde yönetilir.

Dikkat Edilmesi Gerekenler

- Kıdem seviyelerine göre saat ücretleri ayrı yazılmalı

- Aylık bütçe üst sınırı olmalı

- Zaman takip sistemi erişimi verilmelidir

- Her sprint sonunda demo yapılmalı

- Hız, hata ve ilerleme raporları paylaşılmalı

Model 3: Sonuç Bazlı Model

Nasıl Çalışır?

Yazılım firması belirli bir sabit ücret alır. Kalan ödeme ölçülebilir başarı kriterlerine bağlanır.

Örneğin:

“MVP yayına çıktıktan sonraki 90 gün içinde aktif kullanıcı sayısı 1.000’i geçerse kalan ödeme yapılır.”

Ne Zaman İşe Yarar?

- Başarı kriteri net ölçülebiliyorsa

- Yazılım firması alan uzmanlığına sahipse

- Hedef firma tarafından doğrudan etkilenebiliyorsa

Ne Zaman Sorun Çıkarır?

- Başarı kriteri firma kontrolünde değilse

- Sabit ücret çok düşükse

- Ölçüm yöntemi net tanımlanmadıysa

Gerçek Maliyet

Doğru kurulduğunda maliyet kontrolü oldukça başarılıdır.

Yanlış kurulduğunda ise:

- sözleşme tartışmaları,

- kalite düşüşü,

- yarım kalan proje riski oluşur.

Dikkat Edilmesi Gerekenler

- Ölçüm yöntemi sözleşmede açıkça yazılmalı

- Kontrol dışı değişkenler ayrıştırılmalı

- Ölçüm süresi net olmalı

- Sabit ücret sürdürülebilir seviyede tutulmalı

Model 4: Hibrit / Fazlı Model

Nasıl Çalışır?

Proje aşamalara bölünür ve her aşamada farklı model kullanılır.

Faz 1: Keşif

Sabit ücretli analiz süreci

Faz 2: MVP Geliştirme

Süre ve emek bazlı ilerleme

Faz 3: Ölçekleme

Süre bazlı veya sonuç bazlı devam

Faz 4: Bakım

Aylık destek veya hizmet seviyesi anlaşması

Ne Zaman İşe Yarar?

- Büyük ölçekli kurumsal projelerde

- Uzun süreli geliştirmelerde

- Kapsamın zamanla değişeceği durumlarda

-Riskin aşamalı yönetilmek istendiği projelerde

Gerçek Maliyet

En dengeli model genellikle budur.

Başlangıçta yapılan keşif yatırımı, sonraki geliştirme sürecinin daha kontrollü ilerlemesini sağlar.

Hangi Model Hangi Projede Daha Uygun?

Net kapsamlı küçük projeler → Sabit Fiyat

Ar-Ge ve değişken kapsamlı projeler → Süre ve Emek Bazlı

Ölçülebilir başarı hedefi olan projeler → Sonuç Bazlı

Uzun süreli kurumsal projeler → Hibrit Model

Bugün çoğu kurumsal projede en sağlıklı yaklaşım hibrit modeldir.

Çünkü:

- riski dağıtır,

- kontrolü korur,

- tarafları uzun vadeli ortaklığa yaklaştırır.

Sözleşmede Dikkat Edilmesi Gereken 7 Kritik Nokta

1. Saat ücretleri kıdeme göre ayrılmamışsa

2. Keşif yapılmadan sabit fiyat veriliyorsa

3. %50’den fazla peşinat isteniyorsa

4. Ek geliştirme ücretleri tanımlı değilse

5. Gecikme cezaları yoksa

6. Faz geçişleri net değilse

7. Bakım hizmeti zorunlu tutuluyorsa

Bu maddelerin birkaçını aynı anda görüyorsanız, alternatif firmaları değerlendirmek faydalı olabilir.

Sonraki Adım

Fiyatlandırma modeli kararı, vendor seçimiyle birlikte verilmeli. İki yazımız var:

Vendor seçim sürecinde 38 soru için: Kurumsal Yazılım Geliştirme Şirketi Seçimi: 2026 CTO Checklist

ROI hesaplaması için: Özel Yazılım Yatırımının Geri Dönüşü: 2026 ROI Hesaplama Çerçevesi

SaaS vs Custom kararı için: Özel Yazılım mı SaaS mı? 9 Soruluk Karar Çerçevesi

Eğer halihazırda batan bir projeyi kurtarmak istiyorsanız ya da vendor değiştirme aşamasındaysanız, Software Graveyard kurtarma sürecimiz bu durum için tasarlandı.